@SoulKyu Reviewed the fix in internal/webui/templates/scripts/dashboard_core.templ: handleAuthError() now redirects to /login only on response.status === 401, dropping the || response.status === 503 branch. I verified this makes the helper consistent with installFetchInterceptor(), which already only redirects on 401, and confirmed via grep that handleAuthError() is the single choke point used by every dashboard call site (actions, data, modal, resolved-alerts, utilities mixins) — so this one-line change covers all of them as claimed. The regenerated dashboard_core_templ.go matches the .templ source (only the embedded script string changed), and go build ./internal/webui/... succeeds cleanly. Nice, well-scoped fix for a real production annoyance — thanks for tracking down the root cause and keeping the diff minimal!

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Thanks for tracking this down — restricting handleAuthError() to response.status === 401 correctly stops the cache-warm-up 503 from bouncing users to /login, and the regenerated dashboard_core_templ.go matches the .templ diff.

However, per the QA run already recorded on this PR and confirmed below by re-reading the auth path, the change doesn't close the second scenario the PR body itself calls out ("Backend blips hit users mid-incident"). See the inline comment for details and a concrete fix direction. (Posted as COMMENT because GitHub blocks self-authored REQUEST_CHANGES reviews; this is a blocking finding and should not be merged as-is.)

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified the fix at head d120840. The remaining blocking gap from the earlier review round — protected routes answering 401 (with ClearSession) instead of 503 when the backend is merely unreachable — is now properly closed:

• internal/webui/client/backend_client.go: new IsUnavailableError() unwraps the gRPC status and returns true only for codes.Unavailable / codes.DeadlineExceeded, leaving genuine session-rejection errors (e.g. codes.Unauthenticated, plain non-gRPC errors) to fall through as real auth failures.
• internal/webui/middleware/auth.go RequireAuth(): when ValidateSession fails with an unavailable-backend error, it now responds 503 and returns without calling ClearSession, reserving 401 + session-clear for actual invalid/expired sessions.
• internal/webui/templates/scripts/dashboard_core.templ: handleAuthError() redirects to /login only on 401, matching the unchanged installFetchInterceptor() — confirmed via grep that both are now consistent (response.status === 401 in both places, no remaining 503 redirect condition).
• The regenerated dashboard_core_templ.go diff is a single-line change matching the .templ source, and the new TestIsUnavailableError table test covers nil, Unavailable, DeadlineExceeded, a plain non-gRPC error, and Unauthenticated, exercising exactly the classification the fix relies on.

Locally re-verified: go build ./..., go vet ./internal/webui/..., and go test ./internal/webui/client/... ./internal/webui/middleware/... all pass. This closes both scenarios from #118 (cache warm-up and backend-down mid-incident) without touching unrelated call sites. Solid follow-through on the QA feedback — thanks for tracking the root cause all the way through the gRPC error path instead of settling for the surface-level frontend fix.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified at head 1e22b58. The webui-relevant files in this PR (internal/webui/client/backend_client.go, internal/webui/client/backend_client_test.go, internal/webui/middleware/auth.go, internal/webui/templates/scripts/dashboard_core.templ + regenerated _templ.go) are byte-identical to the commit already reviewed and approved as clean in the prior round (d120840) — the only change since then is an unrelated devtools/factory-tui documentation update outside this PR's scope, confirmed via gh pr diff --name-only against the PR's actual file list.

Re-confirmed independently:

• client.IsUnavailableError() correctly unwraps the gRPC status and only returns true for codes.Unavailable/codes.DeadlineExceeded, leaving codes.Unauthenticated and plain non-gRPC errors (e.g. invalid session from ValidateSession) to fall through as real auth failures.
• middleware.RequireAuth() now returns 503 without clearing the session when the backend is merely unreachable, and only clears the session + returns 401 for genuine invalid/expired sessions.
• handleAuthError() in dashboard_core.templ redirects to /login only on 401, matching the unchanged installFetchInterceptor().
• TestIsUnavailableError covers nil, Unavailable, DeadlineExceeded, a plain error, and Unauthenticated.
• go build ./internal/webui/..., go vet ./internal/webui/..., and go test ./internal/webui/client/... ./internal/webui/middleware/... all pass at this head.

This closes both scenarios from #118 (cache warm-up and backend-down mid-incident). Thanks for the thorough follow-through tracking this all the way to the gRPC error classification instead of stopping at the frontend symptom!

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified at head 5bedaa1. This head carries no code changes versus the previously-approved head (1e22b58) — a diff between the two shows zero differences in internal/webui/client/backend_client.go, internal/webui/client/backend_client_test.go, internal/webui/middleware/auth.go, internal/webui/templates/scripts/dashboard_core.templ, and the regenerated dashboard_core_templ.go; only the commit SHAs changed (rebase), not the content.

Re-confirmed independently at this head:

• client.IsUnavailableError() unwraps the gRPC status and returns true only for codes.Unavailable/codes.DeadlineExceeded, leaving codes.Unauthenticated and plain non-gRPC errors to fall through as genuine auth failures.
• middleware.RequireAuth() now responds 503 without clearing the session when IsUnavailableError is true, and only clears the session + returns 401 for real invalid/expired sessions.
• handleAuthError() in dashboard_core.templ redirects to /login only on 401, matching the unchanged installFetchInterceptor().
• TestIsUnavailableError covers nil, Unavailable, DeadlineExceeded, a plain error, and Unauthenticated.
• go build ./internal/webui/..., go vet ./internal/webui/..., and go test ./internal/webui/client/... ./internal/webui/middleware/... all pass at this head.

This closes both scenarios from #118 (cache warm-up and backend-down mid-incident) with no regressions introduced by the rebase. Thanks for the clean, well-tested follow-through — nothing further needed here.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified at head ac9ebaa. This head is a rebase of the previously-approved fix (content-identical to head 1e22b58/5bedaa1c reviewed earlier in this thread) onto the latest main, with no code changes since then.

Independently re-confirmed the full fix:

• internal/webui/client/backend_client.go: IsUnavailableError() unwraps the gRPC status and returns true only for codes.Unavailable/codes.DeadlineExceeded, leaving codes.Unauthenticated and plain non-gRPC errors (e.g. the invalid session error from ValidateSession) to fall through as real auth failures.
• internal/webui/middleware/auth.go RequireAuth(): when ValidateSession fails with an unavailable-backend error, it responds 503 and returns without calling ClearSession, reserving 401 + session-clear for genuinely invalid/expired sessions.
• internal/webui/templates/scripts/dashboard_core.templ handleAuthError(): redirects to /login only on 401, now consistent with the unchanged installFetchInterceptor().
• The regenerated dashboard_core_templ.go diff is a single-line change matching the .templ source.
• TestIsUnavailableError covers nil, Unavailable, DeadlineExceeded, a plain error, and Unauthenticated.

Locally re-ran go build ./..., go vet ./internal/webui/..., and go test ./internal/webui/client/... ./internal/webui/middleware/... — all pass. This closes both scenarios called out in #118 (cache warm-up 503s and backend blips mid-incident) without touching unrelated call sites. Solid, well-scoped fix — thanks for tracking the root cause through the gRPC error classification instead of stopping at the frontend symptom.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified the handleAuthError() frontend change and the IsUnavailableError() + RequireAuth() server-side fix — both correctly stop the 401/503 misclassification for fetch/XHR calls (cache warm-up and alert-modal actions during a backend blip, the two scenarios named in this PR), and go build/go vet/go test ./internal/webui/client/... ./internal/webui/middleware/... all pass at this head. One follow-up worth tracking: two sibling middleware functions share the same pre-fix pattern this PR just corrected in RequireAuth() — see the inline comment for where and why.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Thanks for closing out the earlier review rounds — IsUnavailableError() plus the RequireAuth(), OptionalAuth(), and RedirectIfNotAuth() guards, and the handleAuthError() 401-only redirect, all correctly stop the false-positive auth failures for dashboard fetches and protected-page navigation.

One gap remains that reproduces the exact bug class this PR (and its title, "don't clear session on backend-unavailable in page middleware") sets out to fix. This is a blocking finding despite the COMMENT state below — GitHub rejects self-authored REQUEST_CHANGES reviews on this repo, so the review state alone does not reflect severity here; do not merge as-is.

internal/webui/middleware/auth.go, RedirectIfAuth() (lines 132-146) — this is the fourth middleware function that calls ValidateSession(), and it still has the pre-fix pattern the other three had before this PR:

sessionID := GetSessionID(c)
if sessionID != "" {
    // Check if session is still valid
    _, err := am.backendClient.ValidateSession(sessionID)
    if err == nil {
        // User is already authenticated, redirect away
        c.Redirect(http.StatusFound, redirectTo)
        c.Abort()
        return
    } else {
        // Clear invalid session
        ClearSession(c)
    }
}

Unlike RequireAuth()/OptionalAuth()/RedirectIfNotAuth(), this branch never calls client.IsUnavailableError(err) — every non-nil error from ValidateSession(), including a transient codes.Unavailable/codes.DeadlineExceeded from a backend blip, falls into the else and clears the session cookie via ClearSession(c).

RedirectIfAuth("/dashboard") is wired up in internal/webui/router.go:362 as middleware on the public /login and /register pages. Concrete failure scenario: a user with a perfectly valid session hits a backend blip (the exact "mid-incident" scenario from this PR's own description) while the backend is temporarily Unavailable/timing out. If they land on /login during that window — e.g. after RedirectIfNotAuth 503s them off /dashboard and they retry via /login, or via a stale bookmark/tab — RedirectIfAuth clears their still-valid session cookie before rendering the login page. Once the backend recovers, they're logged out for no reason, even though their session was never actually invalid.

Suggested fix: mirror the pattern already used three times in this file — check client.IsUnavailableError(err) first and, if true, skip ClearSession(c) (e.g. just fall through to c.Next() without redirecting or clearing, same as the OptionalAuth() treatment), only clearing the session in the genuine invalid/expired case.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified the frontend (handleAuthError()) and the three fixed backend guards (RequireAuth(), OptionalAuth(), RedirectIfNotAuth()) at head 9ba08b4 — each now checks client.IsUnavailableError(err) before clearing the session, correctly separating a transient backend outage from a genuinely invalid session.

One gap remains — this is a blocking finding despite the COMMENT state below (GitHub rejects self-authored REQUEST_CHANGES on this repo, so the review state doesn't reflect severity here; do not merge as-is).

internal/webui/middleware/auth.go, RedirectIfAuth() (lines 124-148) still clears a valid session on a transient backend outage — the exact bug class this PR's commit title ("don't clear session on backend-unavailable in page middleware") claims to close. This function isn't touched by this PR's diff, so it can't be inline-anchored; noting it here instead.

This PR's head commit fixes OptionalAuth() and RedirectIfNotAuth() by checking client.IsUnavailableError(err) before calling ClearSession(c). RedirectIfAuth() is the fourth ValidateSession() call site in this same file and still has the pre-fix pattern:

sessionID := GetSessionID(c)
if sessionID != "" {
    _, err := am.backendClient.ValidateSession(sessionID)
    if err == nil {
        c.Redirect(http.StatusFound, redirectTo)
        c.Abort()
        return
    } else {
        // Clear invalid session
        ClearSession(c)
    }
}
c.Next()

Every non-nil error — including a transient codes.Unavailable/codes.DeadlineExceeded from a backend blip — falls into the else branch and clears the cookie via ClearSession(c), with no IsUnavailableError check.

RedirectIfAuth("/dashboard") is wired up in internal/webui/router.go:362 as middleware on the public /login and /register pages. Concrete failure scenario: a user with a valid session hits /login (e.g. a stale bookmark/tab, or after RedirectIfNotAuth 503s them off /dashboard during a blip and they retry via /login) while the backend is transiently Unavailable. RedirectIfAuth clears their still-valid session cookie before rendering the login page. Once the backend recovers, they're logged out for no reason, even though the session was never actually invalid — reproducing the same class of bug this PR sets out to fix, just through the one call site the fix skipped.

This exact function and line range were already flagged as the blocking gap in an earlier review round on this same PR thread; internal/webui/middleware/auth.go is byte-identical between that earlier flagged head and the current head (9ba08b4), so the gap was carried forward unaddressed rather than fixed.

Suggested fix: mirror the pattern used in the three sibling functions — check client.IsUnavailableError(err) first and, if true, skip ClearSession(c) and just fall through to c.Next() (matching the OptionalAuth() treatment: don't redirect away and don't clear the session), only clearing the session in the genuine invalid/expired case.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Reviewed the session-clearing fix across dashboard_core.templ and the three AuthMiddleware functions touched in internal/webui/middleware/auth.go. The 401-only redirect in handleAuthError() and the new client.IsUnavailableError() guard on RequireAuth(), OptionalAuth(), and RedirectIfNotAuth() are correct and match the stated goal of not logging users out on transient backend blips. go build/go vet/go test ./internal/webui/... all pass, and re-running make webui-templates confirms dashboard_core_templ.go matches the .templ source with no drift.

One gap is worth closing before this class of bug is fully put to rest: RedirectIfAuth() in the same file still has the identical issue. See the inline comment for details.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified at head 1cbc455. This closes out the last gap from earlier review rounds: RedirectIfAuth() in internal/webui/middleware/auth.go (lines 132-148) now checks client.IsUnavailableError(err) before the invalid-session else branch, mirroring the pattern already applied to RequireAuth(), OptionalAuth(), and RedirectIfNotAuth() — on a transient backend outage it falls through via c.Next() without calling ClearSession(c) or redirecting, only clearing the session for a genuinely invalid/expired one.

I independently re-checked all four ValidateSession() call sites in this file (grep -n "ValidateSession(" internal/webui/middleware/auth.go) and confirmed each one now has the IsUnavailableError guard — no remaining call site clears a valid session on a mere backend blip. client.IsUnavailableError() in internal/webui/client/backend_client.go correctly unwraps the gRPC status and returns true only for codes.Unavailable/codes.DeadlineExceeded, leaving codes.Unauthenticated and plain non-gRPC errors to fall through as real auth failures, and TestIsUnavailableError covers nil, Unavailable, DeadlineExceeded, a plain error, and Unauthenticated. handleAuthError() in dashboard_core.templ still redirects to /login only on 401, consistent with the unchanged installFetchInterceptor(), and the regenerated dashboard_core_templ.go matches the .templ source.

Locally ran go build ./..., go vet ./internal/webui/..., and go test ./internal/webui/client/... ./internal/webui/middleware/... — all pass at this head (no middleware test files exist, but the client-level IsUnavailableError unit tests exercise the exact classification all four guards depend on).

This closes both scenarios from #118 (cache warm-up 503s and backend blips mid-incident) across every session-validation call site in this package. Great persistence tracking this all the way through four separate middleware functions instead of settling for a partial fix — nice work!

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}

@SoulKyu Verified at head ca541c4. Compared this head against the previously-approved clean fix (1cbc455) and confirmed the only diff is unrelated main-merge noise (the sessionID parameter added to GetUserGroups/SyncUserGroups/GetUserSentryConfig from #148) — every file this PR actually touches for the 503/session-clearing fix is byte-identical to the earlier verified state:

• internal/webui/client/backend_client.go: IsUnavailableError() unwraps the gRPC status and returns true only for codes.Unavailable/codes.DeadlineExceeded, leaving codes.Unauthenticated and the plain fmt.Errorf("invalid session") from ValidateSession() to fall through as genuine auth failures.
• internal/webui/middleware/auth.go: independently re-grepped all four ValidateSession() call sites (RequireAuth, OptionalAuth, RedirectIfNotAuth, RedirectIfAuth) and confirmed each now checks client.IsUnavailableError(err) before calling ClearSession(c) — including RedirectIfAuth (lines 132-148), which was the gap flagged and fixed in the last review round. No remaining call site clears a valid session on a transient backend blip.
• internal/webui/templates/scripts/dashboard_core.templ: handleAuthError() redirects to /login only on 401, matching the unchanged installFetchInterceptor(); the regenerated dashboard_core_templ.go is a single-line diff matching the .templ source.
• TestIsUnavailableError covers nil, Unavailable, DeadlineExceeded, a plain non-gRPC error, and Unauthenticated.

Locally re-ran go build ./..., go vet ./internal/webui/..., and go test ./internal/webui/client/... ./internal/webui/middleware/... — all pass at this head. This closes both scenarios from #118 (cache warm-up 503s and backend blips mid-incident) across every session-validation call site in the package. Great persistence tracking this through four separate middleware functions across many review rounds instead of settling for a partial fix — nice work, nothing further needed here.

_{🔁 Powered by Looper · runner=reviewer · agent=claude-code · An autonomous AI dev team for your GitHub repos.}